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REMARKS 

Claims 1-19 are currently pending. Claims 1-9 and 11-19 are presented for 
consideration. Claim 10 was previously withdrawn from consideration. Claims 1, 
2, 3, 5, 8, and 9 are currently amended. 

Claims 1-4 stand rejected under 35 U.S.C. 102(b) as being anticipated 
by Ribas-Corbera et al., hereinafter Ribas-Corbera. 

Claims 5-9 stand rejected under 35 U.S.C. 102(e) as being anticipated 
by Pejhan et al., hereinafter Pejhan. 

Claims 11-15 stand rejected under 35 U.S.C. 102(e) as being 
anticipated by Zhang et al., hereinafter Zhang. 

Claims 16-19 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Ribas-Corbera in view of Zhang. 

Regarding claim 1, the Office Action puts forth that Ribas-Corbera discloses 
a method for adapting the number of encoded bits produced by a codec to a 
system target bit-rate by determining if the system target bit-rate is such 
that bits-per-macroblock is less than a predetermined number (Ribas-Corbera: 
column 14, lines 50-60). 

Applicants respectfully disagree. As is explained in col. 14, lines 1-4; col. 14, 
lines 18-21; and col. 15, lines 7-9, "P" are frames whose pixels are predicted from a 
previous frame, B are frames whose pixels are bi-directionally predicted using 
previous and future frames in sequence, Tp (formula [28], col. 14, lines 21-24) 
determines how many bits to assign to P frames (col. 15, line 8-9), and Tb (formula 
[29], col. 14, lines 25-28) determines how many bits to assign to B frames (col. 15, 
line 8-9). Thus, Ribas-Corbera: column 14, lines 50-60 describe how to determine 
how many bits should be assigned to P and to B frames, but does not teach at what 
frequency (intra-code) frames should be sent, as is required by the presently 
claimed invention. 

It is further self-evident that Ribas-Corbera does not teach selecting between 
two frequency ranges for sending frames based on a comparison of bits-per- 
macroblock to a fixed predetermined number. 
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Even if one were to try to equate the frequency at which frames are sent to a 
determination of bits per frame, Ribas-Corbera explains that his assignment of bits 
per frame is continuously varying (i.e. not switched between two predetermined 
fixed values), and depends on the fullness level of an encoder buffer (col. 8, lines 25- 
30), and thus not based on a comparison of the bits-per-macroblock to a fixed 
predetermined number. 

Continuing with claim 1, the Office Action also asserts that Ribas-Corbera 
shows based on this bits-per-macroblock to predetermined number comparison, 
assigning one of two bit rates to frames. As is explained above, and as is clear 
from the bit rate assignment formulas [28] and [29] (col. 14, lines 23-29), the 
assigned bit rates do not alternate between two predetermined ranges, but rather 
vary in accordance with multiple factors used to determine fullness level of a 
buffer. 

The Office Action further asserts that, 

"...unless there is motion (Ribas-Corbera: column 10, lines 
35-45) in more than a predetermined percentage of the 
macroblocks, in which case the sending frequency of the 
intra-coded frames is set to the first predetermined 
frequency range (Ribas-Corbera: column 17, lines 35-65)" 

Applicants respectfully point that this cited excerpt merely shows alternate ways of 
writing the Tp/Tb bit rate assignment formulas discussed above. This is made clear 
in col. 17, lines 49-50, wherein Ribas-Corbera explain that, "The parameters in 
Equations (37), (38), and (39) have the same meaning as in previous formulas". 
Thus, Applicants are at loss for determining where in the cited reference is taught 
that if bits-per-macroblock is lower than a fixed predetermined number, then the 
frequency at which intra-coded frames are sent is set to a second range lower than 
a first range unless the frames have motion in more than a predetermined 
percentage of the macroblocks, in which the frequency is set to the first range. 
Clarification is requested. 

The Office Action then puts forth that Ribas-Corbera shows, 

"setting to zero transform coefficients having a zig-zag 
index greater than or equal to a preset number in select 
intra-coded frame transform coefficient blocks (Ribas- 
Corbera: column 13, lines 25-40)" 
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Applicants respectfully point out that zig-zag indices are not mentioned in the cited 
excerpt. Applicants respectfully request clarification of this part of the rejection. 

In reference to claim 4, the Office Action asserts that, 

"Ribas-Corbera further disclose maintaining a count of the 
actual bits used per frame, and , if the accumulated bit 
count exceeds a bit budget for a typical inter-coded frame, 
skipping the encoding of the next inter-coded frame (Ribas- 
Corbera: column 11, lines 25-45)" 

Applicant respectfully point out that in Col. 11, lines 25-45, Ribas-Corbera are 
discussing experimental results obtained from execution of their invention. That 
is, Col. 11, lines 25-45 do not recite steps in Ribas-Corbera's invention, but rather 
show (and discuss) experimentally gathered data. Since this data is merely for 
comparison with pre-existing, known alternate methods of transmitting data in 
order to gain an understanding of how Ribas-Corbera f s method compares with the 
known methods, it is clear that none of the gathered data is used during execution 
of Ribas-Corbera's method for altering the execution of the his method. 

In reference to claim 5-9, the Office Action suggests that Pejhan shows all 
aspects of the claims. 

Applicants respectfully disagree and point out that in column 5, lines 1-6, 
Pejhan recites a selection list of multiple difference coding algorithms (or coding 
modes) from which to choose, but does not recited a list of variable parameters for 
each coding mode (or for any single coding mode). That is, Pejham does not recite 
any variable parameters for any of the 5 recited coding modes, or coding 
algorithms. In column 4, line 66 to column 5 lines 1-6, Pejham explains that 
MPEG-2 provides at least 5 different coding modes, so before one can use the 
"motion compensation prediction" one needs to specify which coding mode will be 
used. That is, one first selects 1 of the 5 different coding modes available. 
Specifically, Pejham states (Col. 4, line 66 to Col. 5, line 6): 

"Furthermore, prior to performing motion compensation 
prediction for a given macroblock, a coding mode must be 
selected. In the area of coding mode decision, MPEG provides a 
plurality of different macroblock coding modes. Specifically, 
MPEG-2 provides macroblock coding modes which include intra 
mode, no motion compensation mode (No MC), frame/field/dual- 
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prime motion compensation inter mode, 

forward/backward/average inter mode and field/frame DCT 
mode." 

It is noted that a macroblock refers to a block of pixels to be encoded (col. 6, lines 
56-60). 

Thus, Pejhan does not teach or suggest variable parameters for changing 
specific settings of a coding algorithm. Once Pejhan's coding mode is selected, no 
option is described for changing variable parameters for the selected coding mode. 

Applicants further respectfully point out that nowhere does Pejhan show a 
decoder having a decoding algorithm with multiple variable parameters to 
changing different settings in the decoding algorithm during operation. 

In regards to claim 11, the Office Action states that, 

"Zhang discloses in an arrangement comprising a plurality 
of clients and at least one server (Zhang: figures 1-2), a 
device configured to respond to a particular client for 
which a region-of-interest is identified in a video to be 
delivered to that client (Zhang: column 6, lines 20-25)" 

Applicants respectfully point out that Zhang, col. 6, lines 20-25 states, 

"Client 230 processes the MSFTP protocol at module 232 and 
passes the media to a demultiplexer module seen in FIG. 2 at 
reference numeral 234. Demultiplexer module 234 
demultiplexes the combined stream into original media types 
for decoding at Video m decoder, Video n decoder, and Audiok 
decoder. The output from the video and audio decoders are 
mixed at a Media Mixer module 236 and output to an output 
device 238, such as a personal computer at Client 230 having a 
display device and having a sound card with associated 
speakers". 

As is self-apparent from the above, Zhang is silent on any "region-of-interest" 
within a video, and thus its relevance to the presently claimed invention is not 
readily apparent. Applicants further put forth that Video m and Video n refer to two 
distinct media streams (see Zhang, Col. 6, line 13). Applicant requests clarification 
of the relevance of the Zhang reference to the presently claimed invention. 
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In view of the foregoing amendments and remarks, Applicants respectfully 
request favorable reconsideration of the present application. 



Respectfully submitted, 



/Rosalio Haro/ 

Rosalio Haro 
Registration No. 42,633 

Please address all correspondence to: 

Epson Research and Development, Inc. 
Intellectual Property Department 
2580 Orchard Parkway, Suite 225 
San Jose, CA 95131 
Phone: (408) 952-6131 
Facsimile: (408) 954-9058 
Customer No. 20178 



Date: October 2, 2008 
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